+ci-status

+ci-run-hosted

CI Status

Head SHA: 57915e607d76
Changed files: 3
Docs-only heuristic (matches ci-changes-detector metadata paths): no
ready-for-hosted-ci label: absent
force-full-hosted-ci label: absent
Current hosted-CI waiver: not present for this SHA

Only the required gate is active unless hosted CI is requested.

Hosted CI Requested

Triggered 9 workflow(s) for 57915e607d76.
Mode: optimized hosted CI (path-selected by script/ci-changes-detector).
Added ready-for-hosted-ci, so future commits will keep running optimized hosted CI until +ci-stop-hosted is used.

View progress in the Actions tab.

Walkthrough

The release task now bounds GitHub release bodies by compacting links and truncating oversized changelog content. It reports prepared-body sizes before publication, centralizes GitHub failure recovery, and documents the GitHub-only synchronization path.

Changes

GitHub release body flow

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseTask
  participant NotesPipeline
  participant GitHub
  participant SyncCommand
  ReleaseTask->>NotesPipeline: Prepare changelog notes
  NotesPipeline->>ReleaseTask: Return bounded release body
  ReleaseTask->>GitHub: Publish release
  GitHub-->>ReleaseTask: Report failure
  ReleaseTask->>SyncCommand: Retry GitHub synchronization

Suggested reviewers: ihabadham

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Greptile Summary

This PR prevents oversized changelogs from blocking GitHub release publication. The main changes are:

• Compacts same-repository issue, pull request, and contributor links.
• Produces bounded, Markdown-safe excerpts when notes remain oversized.
• Runs release-note preparation before confirmation and in recovery flows.
• Prints an idempotent GitHub-only recovery command after publication failures.
• Documents and tests the updated release workflow.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

_{Reviews (1): Last reviewed commit: "Prevent oversized GitHub release failure..." | Re-trigger Greptile}

Review: Prevent oversized GitHub release failures

Overview

This PR fixes a real incident (17.0.0's release body exceeded GitHub's 125,000-char limit) by adding a preflight/prepare step for GitHub release bodies: compact same-repo PR/issue/profile links to short forms, and if still oversized, fall back to a Markdown-safe beginning/end excerpt with a tag-pinned link to the full changelog. The same preparation is applied to both release and sync_github_release, and a publish failure now prints the idempotent recovery command instead of risking a re-run of registry publication.

Code quality

• The implementation is cleanly decomposed into small, single-purpose functions (compact_github_release_notes, truncate_github_release_notes, github_release_escaped_excerpt, etc.), consistent with the rest of release.rake's style (keyword args, shorthand hash punning, abort for fail-closed behavior).
• The binary search in github_release_escaped_excerpt to find the max substring whose escaped length fits a budget is a nice touch — it correctly accounts for CGI.escapeHTML potentially expanding length (e.g. <, >, & in code blocks), and the predicate is monotonic so the binary search is valid.
• The 3/4 (beginning) / 1/4 (ending) budget split favors keeping more context at the top, which seems like a reasonable default, though it's a bit of a magic ratio — a named constant would make the intent self-documenting.
• Wrapping truncated excerpts in escaped <pre> blocks is a good defensive choice: it prevents a truncation cut mid-code-fence or mid-markdown-link from corrupting the rendered page, since the content becomes inert text rather than live Markdown.

Correctness

• Verified the budget math can't cause beginning/ending excerpts to overlap (the sum of their actual budgets is always less than available_characters, which is always less than the oversized notes.length that triggers this path).
• compact_github_release_notes replacements are always length-reducing or neutral, so it can't make an in-limit body larger.
• The <= boundary in github_release_body_within_limit? matches the stated 125,000 limit inclusively, consistent with the PR's own validation against the live v17.0.0 release.
• ensure_github_release_body_within_limit! gives a fail-closed safety net if the budget math is ever wrong (e.g. constant changes), which is good defensive design.
• Left two minor inline nits: (1) prepare_github_release_context re-extracts the changelog and recomputes github_release_notes even though confirm_release!'s preflight already computed it once — harmless but duplicate work; (2) the profile-link compaction regex is a broad heuristic (matches any [x](.../x) link, not just validated GitHub usernames) — likely fine in practice but worth a comment if intentional.

Test coverage

Very thorough — covers compaction with 800 entries, max-length (39-char) usernames, multibyte content near the limit (char vs byte length), balanced <pre> tags across the omission boundary, single oversized entry, and the exact fallback-wrapper budget edge case. This gives good confidence in the binary-search/budget math specifically.

Security

No concerns — this only touches release-body text prepared for gh release create/edit --notes-file (via tempfile, not shell interpolation), and escaping via CGI.escapeHTML is appropriately used for the raw excerpt fallback.

Risk/Blast radius

Low — this is maintainer-only release tooling, gated behind a manual rake release / sync_github_release invocation, with a fail-closed abort if the prepared body still doesn't fit. No user-facing runtime code is touched.

Overall: solid, well-tested fix for a real release-blocking bug. Only minor nits noted inline; nothing blocking.